Skip to content

Conversation

@norrietaylor
Copy link
Member

The Read() function in ec_security_project was not populating the
admin_features_package and product_types fields from the API response,
causing them to remain in an 'unknown' state after resource creation.
This resulted in Terraform errors: 'Provider returned invalid result
object after apply'.

This fix adds the missing field population logic in the Read() function:

  • admin_features_package uses NewStringPointerValue() pattern (matching observability_project pattern for optional pointer fields)
  • product_types is converted from API response format to Terraform list

Updated tests to verify the fields are correctly populated.

Fixes #938

Assisted by Cursor AI.

…_project Read()

   The Read() function in ec_security_project was not populating the
   admin_features_package and product_types fields from the API response,
   causing them to remain in an 'unknown' state after resource creation.
   This resulted in Terraform errors: 'Provider returned invalid result
   object after apply'.

   This fix adds the missing field population logic in the Read() function:
   - admin_features_package uses NewStringPointerValue() pattern (matching
     observability_project pattern for optional pointer fields)
   - product_types is converted from API response format to Terraform list

   Updated tests to verify the fields are correctly populated.

   Fixes elastic#938

   Assisted by Cursor AI.
@norrietaylor norrietaylor requested a review from a team as a code owner November 6, 2025 05:55
@norrietaylor norrietaylor force-pushed the fix/security-project-read-unknown-fields branch 2 times, most recently from 37300d1 to 9644ee7 Compare November 7, 2025 07:15
@norrietaylor norrietaylor force-pushed the fix/security-project-read-unknown-fields branch from 9644ee7 to a957266 Compare November 7, 2025 07:24
resource ec_security_project "%s" {
name = "%s"
region_id = "%s"
admin_features_package = "standard"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to have at least one acceptance test which verifies that these values can be set, and updated successfully by the provider.

type securityModelReader struct{}

// productTypesOrderInsensitivePlanModifier ignores order differences in product_types list
type productTypesOrderInsensitivePlanModifier struct{}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the comment here, I think we actually want to create a custom type for the product types. That type can then implement ListValuableWithSemanticEquals which:

  • Applies the same logic as this plan modifier during the planning phase
  • Critically, applies the same logic during the post application checks which will avoid the inconsistent state error I imagine we'd get if the TF config defined product types in a different order to what was returned by the API.

productTypeValues := []attr.Value{}

if len(sourceProductTypes) > 0 {
// Use the ordering from state/config, but with values from API
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the custom type comment above. We can bundle all this logic i.e the plan modifier and this ordering shenanigans into the custom type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] ec_security_project - provider returns an error indicating that admin_features_package and product_types are unknown values

2 participants